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PRESENTATION OF SINGLE-HIT DECISION TABLES 

(ISO Title : Information Processing — Specification of Single-Hit 

Decision Tables ) 



National Foreword 

This Indian Standard, which is identical with ISO 5806-1984, 'Information processing — 
Specification of single-hit decision tables', issued by the International Organization for Standardiza- 
tion (ISO), was adopted by the Bureau of Indian Standards on the recommendation of the 
Computers, Business Machines and Calculators Sectional Committee and approval of the Electronics 
and Telecommunication Division Council. 

In the adopted standard certain terminology and conventions are not identical with those used 
in Indian Standards; attention is specially drawn to the following: 

Wherever the words 'International Standard' appear referring to this standard, they should be 
read as 'Indian Standard'. 
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programming tion 7 Digital computer programming 
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1 Scope and field of application 

This International Standard specifies the basic format of single- 
hit decision tables and the relevant definitions, together with 
recommended conventions for preparation and use. 



3.5 "ELSE"-rule: The actions to be taken for all combi- 
nations of conditions not covered by the other rules in the 
table. 

NOTE — The use of the ELSE-rule facility is optional. 



NOTES 

1 This International Standard is concerned with the use of decision 
tables in the context of the documentation of computer-based infor- 
mation systems. It is not concerned with other uses, such as for the 
representation of program statements. 

2 The format and conventions for the preparation and use of 
"multiple-hit" decision tables are outside the scope of this International 
Standard. 



2 References 

ISO 2382, Data processing — Vocabulary — 
Part 1: Fundamental terms. 
Part 7: Digital computer programming. 



3.6 condition: A description of a contingency to be con- 
sidered in the representation of a problem, or a reference to 
other procedures to be considered as part of the condition. 

3.7 action : A description of an operation to be taken in the 
formulation of a solution. 



3.8 condition entry: An indication of the relevance of a 
condition to a particular rule. 

3.9 action entry: An indication of the relevance of an action 
to a particular rule. 

3.10 condition stub: A list of all the conditions to be con- 
sidered in the description of a problem. 



3 Definitions 

For the purpose of this International Standard the following 
definitions apply. 

3.1 decision table: A table of all contingencies that are to 
be considered in the description of a problem together with the 
action to be taken (from ISO 2382/1). 

3.2 "single-hit" decision table: A decision table where any 
set of conditions will be satisfied by one, and only one, rule. 

3-3 "multiple-hit" decision table: A decision table where 
at least one set of conditions will be satisfied by more than one 
rule (see note 2 to clause 1), 

3.4 rule: A single column through the condition and action 
entry parts of the table, defining a unique set of conditions to 
be satisfied and the actions to be taken in consequence. A rule 
is satisfied if all conditions meet the condition entries of the 
rule. 



3.11 action stub: A list of aU the actions to be taken in the 
solution of a problem. 

3.12 table heading: The symbolic name or other means of 
referencing a decision table from other documents. Alterna- 
tively, or in addition, a clear description of the table. 

3.13 initialisation section: An optional list of unconditional 
actions to be executed sequentially before the first condition is 
examined ; it may be written in the row which follows that of 
the table heading. 

3.14 limited entry table: A decision table where all the con- 
ditions and actions are completely described without reference 
to the rules (see annex B, example 1). 

3.15 extended entry table: A decision table where the con- 
ditions and actions are generally described but are incomplete: 
the specifications are completed by the values specified in the 
rules (see annex B, example 2). 



IS : 12372-1987 
ISO 5806-1984 



3-16 mixed entry table: A decision table whose stub con- 
sists of rows in which limited and extended entries are written 
(see annex B, example 4). 



4 Format 



4.1 Decision tables 



3.17 complete table: A decision table where for all com- 
binations of condition entries there exists a satisfying rule. 

NOTE — In practical terms extended entry tables wilt include limited 
entries and are therefore mixed entry tables. Any extended or mixed 
entry table may be transformed into a limited entry table (see annex 8, 
example 3). 



The general representation of a decision table is given in 
figure 1 . 

The body of the table shall be divided into four parts by double 
lines, drawn close (or alternatively, single thick lines) : this is to 
separate the condition parts from the action parts, and stubs 
from entries. 



Table heading 

(see 3.12) 

First condition 
(see 3.6) 



Last condition. 

First action 
(see 3.7) " 



Last action - 



r*\ 



r~\ 



u 3 



o w 

11 



V 



First rule 
(see 3.4)" 



¥ 



First condition entry 
* (see 3.8) 



■ Lqst condition entry 

First action entry 
"(see 3.9) 



- Last action entry 



Last rule (optional 
"position for ELSE-rule) 



Figure 1 — General format 



NOTE - The reading of a decision table may be facilitated by drawing: single thin horizontal lines between 
separate conditions, and similarly for separate actions; single thin vertical lines between separate rules. Con- 
ditions, actions and rules of a decision table may optionally be named, to allow a unique reference. 
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4.2 Condition entries 



Form 


Meaning within rule 


Application 


Y 


The stated condition shall be fulfilled in satisfying this rule 
<Y - "Yes"). 


limited 
entries 


N 


The stated condition shall not be fulfilled in satisfying this rule 
(N = "No"). 


Text, 

a value 

or a code 


The text (or value or code) completes the specification of the other- 
wise incomplete condition for this rule; the condition shall then be 
fulfilled in satisfying the rule. If a code is used then it shall be 
described in a cross-referenced note. 


extended 
entries 


- 


The stated condition is not relevant to the satisfaction of the rule: 
alternatively, the condition is logically impossible in the context of this 
rule; this may optionally be emphasized by the symbol "#" instead 
of"-" 


any type 
of entry 



NOTE — Any binary notation may be used to designate condition values. 



4.3 Action entries 



Form 


Meaning within rule 


Application 


X 


The stated action shall be taken when this rule is satisfied. 


limited 
entries 


Text, 

a value 

or a code 


The text (or value or code) completes the specification of the other- 
wise incomplete action for this rule; the action shall be taken 
when the rule is satisfied. If a code is used then it shall be de- 
scribed in a cross-referenced note. 


extended 
entries 


- 


The stated action shall not be taken when this rule is satisfied. 


any type 
of entry 



5 Relationships between table elements 

5.1 Conditions 

The relationship between successive conditions is the logical 
"AND": the first condition to be tested is assumed to be 
preceded by "IF". [Example: IF (first condition) AND (second 
condition), . . ., AND {last condition)]. 

The order in which conditions are listed may be of importance. 
However, if the order is of no importance, tables may be easier 
to read if the more important, or "key" conditions are stated 
first : such a sequence might differ from the sequence preferred 
in programming. 



In any rule the last action to be taken should indicate where the 
next procedure is described unless the table is complete in 
itself. 



5.3 Rules 

The relationship between successive rules is the logical ex- 
clusive "OR". 

The sequence of rules in a decision table is irrelevant: note, 
however, the convention that if an ELSE-rule is used then, to 
aid readability, it generally appears as the last rule in the table 
(see figure 1). 



5.2 Actions 

The relationship between actions means successive execution: 
the first action to be taken is assumed to be preceded by 
"THEN", and the first action, the second action, . . . , and the 
last action are successively executed. 

Actions shall be stated in the order in which they are to be 
taken: where the execution sequence differs between rules 
then the actions shall be described as many times as necessary 
to show the various sequences. The use of sequence numbers 
is not recommended due to possible confusion with extended 
entry codes (see 4.3). 



6 Relationships between decision tables 

A large, and/or complex, problem may be described by a set of 
decision tables. There are four types of relationship, which may 
be combined: 

a) sequence; ♦ 

b) selection; 

c) repetition; 

d) nesting. 
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When decision tables are related then each shall be logically 
complete. The conditions in one table shall be tested in- 
dependently of the results of condition tests in another: the 
effect of this requirement is that there is no relationship be- 
tween the rules of related tables. This does not preclude such 
practices as the result of a condition test in one table being in- 
dicated through an action in that table (for example setting a 
flag) so that the indication may be inspected through a con- 
dition test in a subsequent table. 

6.1 Sequence relationship 

Two decision tables form a sequence if the first table has an im- 
mediate successor, as shown in figure 2. More than two deci- 
sion tables may also form a sequence if the same general rule 
applies, that is, the nth is the only immediate successor to the 
(rt-1)th. 

It is recommended that in a sequence the preceding table shall 
include an action providing a pointer to the succeeding table. 



This action will be the last to be taken in any rule where the suc- 
ceeding table must be subsequently interpreted. 

6.2 Selection relationship 

Decision tables form a selection if the first table has more than 
one alternative immediate successor, as shown in figure 3. 

It is recommended that in a selection the preceding table shall 
include actions providing pointers to the successive tables. The 
appropriate action will be the last to be taken in any rule where 
one of the succeeding tables must be subsequently interpreted. 

6.3 Repetition relationship 

A decision table may be interpreted by repetition if at least one 
rule requires re-examination of the condition in that table (see 
figure 4). Such a rule, or rules, require(s) to take as a last action 
some pointer to the same table. 



TABLE 1 



PROCESS TABLE 2 



TABLE 2 

















Figure 2 — Sequence of decision tables 
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TABLE 1 



PROCESS TABLE 2 



PROCESS TABLE 3 



TABLE2 















TABLE 3 















Figure 3 — Selection of decision tables 



I 


TABLE 1 






















REPEAT TABLE 1 










^ 





Figure 4 — Repetition of a decision table 
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6.4 Nesting relationship 

Two decision tables have a nesting relationship if one table is 
completely interpreted whilst testing a condition (see figure 5) 
or taking an action (see figure 6) in the other. The relationship is 
as defined for nesting routines (see ISO 2382/7). 

The nesting table will require some appropriate form of pointer 
in the relevant condition, or action, to the nested table. The 



nested table will require an action which similarly points back to 
the nesting table. This action shall be the last taken for any rule 
in the nested table which is to continue the nesting relation- 
ship. The point indicated in the nesting table will be: for a con- 
dition, the condition from which the original exit was made, 
since the results of interpreting the nested table will be relevant 
to the test of that condition; for an action, the next relevant 
action. 



\~r 



TABLE 1 



(PERFORM TABLE 2) 
CONDITION TEST 



TABLE 2 



RETURN TO TABLE 1 



NOTE - In this example, before CONDITION TEST in TABLE 1 is tested, TABLE 2 is executed and then CONDITION TEST in TABLE 1 is tested. 



Figure 5 — Nested tables (exit at condition) 
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I 



TABLE A 


J 














PERf GRM TABLE B 













TABLES 














RETURN TO TABLE A 





1 



Figure 6 — Nested tables (exit at action) 
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6.5 Combinations of relationships 

Any permutation of relationships may be used as necessary to 
describe the problem and its solution. Figure 7 illustrates a 
number of combined relationships. 

TABLE 1 has two rules requiring repetition of that table. Two 
other rules sequence to TABLE 2. TABLE 2 has two rules se- 
quencing further to TABLE 3 and two rules to TABLE 4. 



TABLES 3 and 4 each have a nesting relationship with TABLE 5 
in order to evaluate a condition. 

The selection available from TABLE 1 is either 

— repetition of TABLE 1 ; 

— sequencing to TABLES 2, 3/nesting to 5; or 

— sequencing to TABLES 2, 4/nesting to 5. 



I 


TABLE 1 




































TABLE 2 



rz: 

I m TABLE 3 



J [ 



TABLE 4 



*i TABLE 5 



Figure 1 — Combined relationships 
10 
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7 Interpretation of decision tables 

7.1 Columnar method 

The satisfied rule is found by determining the particular case 
and then comparing this case with each of the rules in turn. The 
steps required are 

a) test all conditions and identify their values for the par- 
ticular i 



b) compare the values found with each rule in turn until a 
single identical set of values is found and take all the actions 
specified for that rule, in sequence; 

c) if no rule is satisfied by the values for the particular case 
then all the actions specified for the ELSE- rule shall be taken 
in sequence. 

7.2 Linear method 

The satisfied rule is determined by a sequential test of each 
condition in turn. The steps required are 

a) test the first condition; 

b) ignore all those rules which are not satisfied by the 
result of this condition test; 

c) test the next condition which is relevant to the remain- 
ing rules: in effect this means ignoring any remaining con- 
ditions with only " — " condition entries (see 4.2) . If the next 



condition has " — " entries for some, but not all, of the 
remaining rules then the condition is only tested for rules 
specifying other than "— " entries; 

d) repeat steps b) and c) until all conditions have been 
examined, i.e. being tested or ignored; 

e) either a single rule is found which is satisfied by ail the 
results of the condition tests or, if no rules remain then the 
ELSE-rule applies: whichever is true the actions specified 
for that rule are taken in sequence. 



7.3 Completeness 

By definition (see 3.2) the results of either method of interpret- 
ation must result in one, and only one, rule being satisfied. If an 
ELSE-rule is included in the table then, by definition (see 3.5), it 
cannot apply to a case which is satisfied by a specified rule. 

Any table which includes an ELSE-rule is always complete. The 
ELSE-rule is, in effect, a default rule. The employment of an 
ELSE-rule requires care since it will be followed instead of rules 
omitted from the table by mistake. 

If a table does not include an ELSE-rule then all logically poss- 
ible permutations of conditions should be specified. For such a 
table care shall be taken in its preparation so that no permu- 
tation will be uncovered. The verification of completeness is an 
essential part of preparation. 



11 
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Annex A 



Recommendations for preparation 

(This annex forms part of the standard.) 



A.1 Condition entry construction 

It is recommended that when a decision table is first drafted the 
full permutation of condition entries is listed before any attempt 
is made to reduce the size of the table. This will ensure that no 
combination of conditions is overlooked. 

The complete number of rules in any table is always the prod- 
uct of the number of values permitted for each condition entry. 

Example: A table has three conditions. For the entries 

a) condition 1 has two values; 

b) condition 2 has three values; 

c) condition 3 has four values. 

Complete number of rules - 2 x 3 x 4 = 24 

The general procedure for constructing entries is therefore as 
follows: 

— Step 1 : Divide the total number of rules by the number 
of values permitted for the first condition entry, This will 
give the number of consecutive rules required for each of 
those values. 



— Step 2: Divide the quotient from step 1 by the number 
of values for the next condition entry, to obtain the number 
of consecutive rules for each value. 

— Step 3: Continue dividing each successive quotient by 
the number of values for successive conditions. The final 
quotient should be 1. 

Example: An extended entry table has three conditions: 

a) condition 1 has two values: Y, N; 

b) condition 2 has three values: A, B, C; 

c) condition 3 has four values: 1, 2, 3, 4. 

Complete number of rules = 2x3x4 = 24 

— Rules per value, condition 1 = 24 ■*• 2 = 12 
(i.e. 12 x Y's, 12 x N's). 

— Rules per value, condition 2 = 12 ■+■ 3 = 4 
{i.e. 4 x A's, 4 x B's, 4 x C's). 

— Rules per value, condition 3-4-^4=1 
(i.e. one men of 1, 2, 3, 4). 

The complete permutation of condition entries is therefore as 
follows : 



Condition 1 | Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


N 


N 


N 


N 


N 


N 


N 


N 


N 


N 


N 


N 


Condition 2 J A 


A 


A 


A 


B 


B 


B 


B 


C 


C 


C 


C 


A 


A 


A 


A 


B 


B 


B 


B 


C 


C 


C 


C 


Condition 3 | 1 


2 


3 


4 


1 


2 


3 


4 


1 


2 


3 


4 


1 


2 


3 


4 


1 


2 


3 


4 


1 


2 


3 


4 



MOTE — This method is cumbersome for large tables, and other methods of assuring completeness should be 
sought. 
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A.2 Splitting up tables 

For certain types of problems the number of conditions may be 
such that the number of rules is very large. A table which can- 
not be written on one sheet of paper becomes difficult to read. 
It is recommended that such tables be split up at some logical 
boundary to produce two or more tables, arranged in a suitable 
sequence or selection (see 6.1, 6.2). 



One method of splitting is as follows: Construct a table based 
upon the first condition entry having only a single value. For 
each of the other permitted values of that entry provide a single 
rule: the "dash" symbol is then inserted in such rules for sub- 
sequent condition entries and a single action is provided refer- 
encing the succeeding table(s). 



Example: 



Condition 1 


A 


A 


A 


A 


A 


A 


A 


A 


A 


B 


C 


Condition 2 


20 


20 


20 


30 


30 


30 


40 


40 


40 


- 


- 


Condition 3 


P 


Q 


R 


P 


Q 


R 


P 


Q 


R 


- 


- 


Process table 2 




















X 


- 


Process table 3 


- 




















X 
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A. 3 Table simplification 

Extended or mixed entry tables can only be simplified by in- 
spection. This can be a particuiariy difficult exercise. 



Note that for many tables it is possible to reduce the size owing 
to the presence of mutually exclusive conditions. In the 
example shown below the two conditions can obviously be 
amalgamated. 



I inrii+oH ontw t^aKInf nrtow Ka l _ . . _ 

described below, are satisfied. 

Any two rules may be combined if, and only if 

a\ thov/ rr^ntaln nrericolv/ tho camo rnmhinatinn and co- 

quence of actions; 

b) their condition entries differ by only a single row. 

In the combined rule the "Y" and "N" entries are replaced by 
the dash symbol (" — "). 

It may be possible to combine pairs of previously combined 
rules, following the above procedure. It should, however, be 
noted that a dash symbol in the condition entry of one ruie does 
not mean the same as a "Y" or "N" of another. 



Example: 



a) Full table 



Condition A 


Y 


Y 


Y 


Y 


N 


N 


N 


N 


Condition B 


Y 


Y 


N 


N 


Y 


Y 


N 


N 


Condition C 


Y 


N 


Y 


N 


Y 


N 


Y 


N 


Action P 


- 












X 


X 


Action Q 


- 


- 


- 


- 


- 


X 


- 


- 


Action R 


X 


X 


X 


X 


X 


- 


X 


X 


Action S 


X 


X 


X 


X 


X 


- 


- 


- 



In this table the first four rules may be combined. The fifth rule 
has the same actions but cannot be combined. The seventh 
and eighth rules may also be combined. 

b) Simplified table 



Condition A 


Y 


M 


N 


N 


Condition 8 


- 


Y 


Y 


N 


Condition C 


- 


Y 


N 


- 


Action P 


- 


- 


- 


X 


Action Q 


- 


- 


X 


- 


Action R 


X 


X 


- 


X 


Action S 


X 


X 


- 


- 



MALE EMPLOYEE? 



FEMALE EMPLOYEE? 



A. 4 Rule count checking 

As stated earlier (see A.1) the complete number of rules in any 
table is the product of the number of values permitted for each 
condition. This fact may be used to check the completeness of 
a table, using the following procedure: 

a) Step 1 : For each "simple'' rule {i.e. one which contains 
no dash symbols) count "1" 

b) Step 2: For each rule containing dash symbols the 
count is the product of its ''factors" : if a condition has a 
specific value the factor is 1 ; if the dash symbol is used the 
factor is the number of alternative values represented by the 
dash. 

c) Step 3: Add the number of counts together to obtain 
the total number of rules in the completed table and com- 
pare with the expected number. 

Where an "ELSE" rule has been used, the rule count may not 
be readily checked : the number of rules involved shall be de- 
rived by examination. 

Example: From the table shown as* example 1, annex B, the 
following counts may be obtained: 4, 2, i, 1, 8. The totai 
number of "simple" rules is therefore 16. 
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Example 1 — Limited entry decision table 



Example 2 — Extended entry decision table 



Table 3 — Control breaks 


Any more records 


Y 


Y 


Y 


Y 


N 


Same employee as previous 


Y 


N 


N 


N 


- 


Same dept. as previous 


- 


Y 


N 


N 


- 


Same divn. as previous 


- 


- 


Y 


N 


- 


Merge records 


X 


- 


- 


- 


- 


Print employee details 


- 


X 


X 


X 


X 


Update dept. totals 


- 


X 


X 


X 


- 


Print dept. totals 


- 


- 


X 


X 


X 


Update divn. total 


- 


- 


X 


X 


X 


Clear dept. totals 


- 


- 


X 


X 


- 


Print divn. totals 


- 


- 


- 


X 


X 


Update gross totals 


- 


- 


- 


X 


X 


Clear divn. totals 


- 


- 


- 


X 


- 


Print new headings 


- 


- 


X 


X 


- 


Process table 2 


- 


X 


X 


X 


- 


Process table 4 


X 


- 


- 


- 


- 


Close down 


- 


- 


- 


- 


X 



Table 7 — Deduction analysis 


Grade = 


- 


1 


1 


2 


2 


3 


3 


4 


4 


Deduction code = 





A 


B 


A 


B 


A 


B 


A 


B 


Set deduction value = 





10 


20 


10 


30 


20 


40 


30 


60 


Process table 


6 


8 


8 


8 


8 


9 


9 


9 


9 



Example 3 — Conversion of extended entry table to limited entry 

The limited entry table below is an example of how the extended entry table shown at example 2 
above might be converted. Note that for logical completeness an "ELSE" rule has been introduced 
together with an additional action row. 



Table 7 — Deduction analysis 


Grade = 1 


- 


Y 


Y 


N 


N 


N 


N 


N 


N 


E 
L 
S 

E 


Grade ~ 2 


- 


N 


N 


Y 


Y 


N 


N 


N 


N 


Grade = 3 


- 


N 


N 


N 


N 


Y 


Y 


N 


N 


Grade = 4 


- 


N 


N 


N 


N 


N 


N 


Y 


Y 


Deduction code = 


Y 


N 


N 


N 


N 


N 


N 


N 


N 


Deduction code = A 


N 


Y 


N 


Y 


N 


Y 


N 


Y 


N 


Deduction code - B 


N 


N 


Y 


N 


Y 


N 


Y 


N 


Y 


Set zero deduction 


X 




















Set deduction value = 10 


- 


X 


- 


X 


- 


- 


- 


- 


- 


- 


Set deduction value = 20 


- 


- 


X 


- 


- 


X 


- 


- 


- 


- 


Set deduction value = 30 


- 


- 


- 


- 


X 


- 


- 


X 


- 


- 


Set deduction value = 40 


- 


- 


- 


- 


- 


- 


X 


- 


- 


- 


Set deduction value - 60 


















X 


- 


Process table 6 


X 




















Process table 8 


- 


X 


X 


X 


X 


- 


- 


- 


- 


- 


Process table 9 


- 


- 


- 


- 


- 


X 


X 


X 


X 


- 


Process table 20 




















X 
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Example 4 — Mixed entry decision table 



BASIC-UPDATE (table 13) 


End of transaction file 


Y 


Y 


N 


N 


N 


N 


N 


N 


N 


N 


n 


N 


N 


N 


End of master input file 


Y 


N 


N 


N 


N 


N 


N 


N 


N 


N 


N 


N 


N 


Y 


Key comparison T : MO = 


- 


- 


< 


< 


< 


< 


= 


= 


= 


= 


= 


> 


> 


- 


Tcode - 


- 


- 


I 


I 


A 


D 


I 


I 


A 


D 


D 


- 


- 


- 


INDset 


- 


- 


Y 


N 


- 


- 


Y 


N 


- 


Y 


N 


Y 


N 


-■ 


Perform update-routine (table 15) 


- 


- 


- 


- 


- 


- 


- 


- 


X 


- 


- 


- 


- 


- 


Write MO file 


X 


X 




















X 


X 


- 


Read new Ml 


- 


X 


- 


- 


- 


- 


- 


- 


- 


- 


X 


- 


X 


- 


Move Ml to MO 


- 


X 
















X 


X 


X 


X 


- 


Move T to MO 








X 






















Set IND 








X 






















Unset IND 


- 


- 


- 


- 


■ - 


- 


- 


- 


- 


X 


- 


X 


- 


- 


Read new T 


- 


- 


- 


X 


- 


- 


- 


- 


X 


X 


X 


_ 


_ 


_ 


Set error code *= 


- 


- 


1 


- 


2 


2 


3 


4 














Process error-routine (table 22) 


- 


- 


X 


- 


X 


X 


X 


X 














Process end-routine (table 21) 


X 




























Process basic-update (table 13) 


- 


X 


- 


X 


- 


- 


- 


- 


X 


X 


X 


X 


X 


- 


Process secondary-update (table 14) 




























X 



Code used 

Ml ~ record in master file input area 

MO = record in master file output area 

T = record in transaction file input area 

IND ~ indicator that MO holds previously inserted record 

A = amendment transaction 

D - deletion transaction 

I = insertion transaction 
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